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Abstract 


Since the late 1980s, IEEE 802 and IETF have cooperated in the 
development of Simple Network Management Protocol (SNMP) MIBs and 
Authentication, Authorization, and Accounting (AAA) applications. 
This document describes the policies and procedures that have 
developed in order to coordinate between the two organizations, as 
well as some of the relationship history. 
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1. Introduction 


Since the late 1980s, participants in IEEE 802 and the IETF have 
cooperated in the development of Management Information Bases (MIBs) 
and Authentication, Authorization, and Accounting (AAA) applications 
relating to IEEE standards. This has included the Bridge MIB 
[RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB 
[RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like 
Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces 
Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X 
RADIUS usage guidelines [RFC3580], the revised Extensible 
Authentication Protocol (EAP) specification [RFC3748], RADIUS/EAP 
[RFC3579], and the EAP State Machine specification [RFC4137]. This 
document describes the policies and procedures that have been put in 
place to encourage cooperation between the IETF and IEEE 802. 
Details of the relationship history are included in Appendix A. 


In order to improve communications between the IETF and IEEE 802, 
members of the Internet Engineering Steering Group (IESG) and 
Internet Architecture Board (IAB) (including Bert Wijnen, James 
Kempf, and Bernard Aboba) met with the IEEE 802 Executive Committee 
in Vancouver, Canada, in January 2004. At that meeting, a number of 
issues were discussed and new procedures were put in place. 


1.1. Liaison Communications 


IETF Working Groups are organized into areas, which have one or more 


Area Directors. The Area Directors, plus the IETF Chair, comprise 
the Internet Engineering Steering Group (IESG). IEEE 802 Working 
Groups have one or more Task Groups. The IEEE 802 Working Group 


Chairs, plus the IEEE 802 Chair, comprise the IEEE 802 Executive 
Committee (ExComm). 


Participants in the IETF are appointed as liaisons to other 
organizations by the IAB or IESG as appropriate. This includes a 
liaison to IEEE 802 as well as liaisons to specific IEEE 802 Working 
Groups. The IETF liaison web page includes a list of IETF liaisons, 
as well as a pointer to the archive of liaison statements received by 
the IETF [Liaison-Page]. IETF processes for management of liaison 
relationships are described in [BCP102]; procedures for handling of 
incoming liaison statements are described in [BCP103]. In order to 
ensure that liaison statements from IEEE 802 to the IETF are archived 
and responded to, IEEE 802 liaisons to IETF should utilize the IETF 
liaison management tool to submit liaison communications. A username 
and password suitable for use with the tool can be obtained by 
sending mail to iesg-secretary@ietf.org. If a liaison management 
account is not available, liaison communications can be sent to the 
IETF liaison(s) to IEEE 802 and copied to statements@ietf.org. 
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ak 


T; 


However, in this case substantially greater processing delays will 
occur due to the need for manual handling by the IETF Secretariat 
staff. 


Liaison requests from the IETF to IEEE 802 should be sent to the 
Chair(s) of the IEEE 802 WG to which the request pertains, with a 
copy sent to the IEEE 802 Chair and the IEEE 802 liaison(s) to IETF. 
IEEE 802 procedures for communicating with other standards bodies are 
described in Section 14.1 of [Policy]. Liaison communications to 
IEEE 802 WGs are archived by the individual WGs. 


.2. Access to IEEE 802 Archives 


Access to IEEE 802 standards more than six months old is provided 
free of charge on the IEEE 802 website via the Get IEEE 802 Program 
[GetIEEE-802]. Access to IEEE 802 work-in-progress has frequently 
arisen as an issue in cooperation between IETF and IEEE 802. While 
in the past IETF Working Groups (WGs) have successfully negotiated 
access to IEEE 802 work-in-progress, each instance has been handled 
separately and took significant time and effort to complete. In 
order to more easily enable document access for IETF WGs 
collaborating with IEEE 802, a liaison statement was sent to the IETF 
in July 2004 by Paul Nikolich, Chair of IEEE 802 [IEEE-802Liaison], 
describing the process by which IETF WGs can obtain access to IEEE 
802 work-in-progress. IEEE 802 WG Chairs have the authority to grant 
membership in their WGs, and can use this authority to grant 
membership to an IETF WG chair upon request. The IETF WG chair will 
be provided with access to the username/password for the IEEE 802 WG 
archives, and is permitted to share that information with 
participants in the IETF WG. Since it is possible to participate in 
IETF without attending meetings, or even joining a mailing list, IETF 
WG chairs will provide the information to anyone who requests it. 
However, since IEEE 802 work-in-progress is copyrighted, 
incorporating material into IETF documents or posting the 
username/password on mailing lists or websites is not permitted. 


3. New Work Review 


In order to enable IEEE 802 review of proposed IETF WG charters, as 
well as to enable IETF review of proposed IEEE 802 Project 
Authorization Requests (PARs), the New Work mailing list is used. 

The IEEE 802 Executive Committee is subscribed to the list, so that 
it can receive proposed IETF WG Charters. Proposed IEEE 802 PARs are 
posted to the New Work list as well. Where a New Work announcement 
is of particular interest, it is also (manually) forwarded to the 
relevant IETF and IEEE 802 mailing lists. 
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However, by the time an IETF WG Charter or IEEE 802 PAR appears on 
New Work, a IETF BOF or IEEE 802 "Call for Interest" has already 
occurred, interest has been demonstrated and considerable work has 
gone into development of the Charter or PAR. If problems are found 
at that point, it is often too late in the process to make major 
changes. Therefore, where a potential work item is likely to be 
controversial, discussions between IETF and IEEE 802 are encouraged 
to occur earlier in the process. 


1.4. MIB Review 


With travel budgets under pressure, it has become increasingly 
difficult for companies to fund employees to attend both IEEE 802 and 
IETF meetings. As a result, an alternative is needed to past 
arrangements that involved chartering MIB work items within an IETF 
WG. In order to encourage wider review of MIBs developed by IEEE 802 
WGs, it is recommended that Simple Network Management Protocol (SNMP) 
MIBs developed in IEEE 802 follow the MIB guidelines [RFC4181] and be 
reviewed as part of the IETF SNMP quality control process (’MIB 
Doctors’). An IEEE 802 group may request assignment of a ’MIB 
Doctor’ to assist in a MIB review by contacting the IETF Operations 
and Management Area Director. 


By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing 
the SNMP quality control process, the IETF and IEEE 802 seek to 
ensure quality while decreasing overhead. A trial run of this 
process has taken place in IEEE 802.1 where a MIB Doctor (David 
Harrington) has agreed to review IEEE 802.1 MIBs. Currently, 
discussion is under way on how change control of selected IEEE 802.1 
MIB documents published as RFCs can be transferred to IEEE 802.1 
[MIB-TRANSFER]. 


1.5. EAP Review 


Several IEEE 802 standards, including [IEEE-802.1X-2004], 
[IEEE-802.11i], and [IEEE-802.16e], depend on EAP [RFC3748] and EAP 
key management, described in [KEYFRAME]. Rather than developing 
their own EAP methods, or extensions for EAP key management, IEEE 802 
working groups should send a liaison letter to the IETF, outlining 
the required functionality or requesting a review of draft text. 

Most recently, a security review of IEEE 802.16e D8 [EAPREVIEW] has 
been carried out by the EAP WG, at the request of the IEEE 802.16 
Chair, Roger Marks [IEEE-802.16-Liaisonl] [IEEE-802.16-Liaison2]. 
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1.6. AAA Review 


IEEE 802 WGs requiring new AAA applications should send a liaison 
request to the IETF. Where new attributes are required rather than a 
new application, an Internet-Draft can be submitted and review can 

be requested from AAA-related WGs such as the AAA or RADEXT WGs. For 
attributes of general utility, and particularly those useful in 
multiple potential applications, allocation from the IETF standard 
attribute space is preferred to creation of IEEE 802 Vendor-Specific 
Attributes (VSAs). As noted in [RFC3575]: 


RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 
26) and the use of that should be encouraged instead of allocation of 
global attribute types, for functions specific only to one vendor’s 
implementation of RADIUS, where no interoperability is deemed useful. 


Where allocation of VSAs are required, it is recommended that IEEE 
802 create a uniform format for all of IEEE 802, rather than having 
each IEEE 802 group create their own VSA format. The VSA format 
defined in [IEEE-802.11F] is inappropriate for this, since the Type 
field is only a single octet, allowing for only 255 attributes. 
Recently, the AAA Doctors list has been created within the IETF 
Operations and Management Area Directorate, serving a similar 
function to the MIB Doctors. While the AAA Doctors have not yet been 
called upon to assist with and review AAA work outside of the IETF, 
this group could potentially be of assistance to IEEE 802 working 
groups requiring help with AAA. 


1.7. Document Review 


With the areas of cooperation between IEEE 802 and IETF increasing, 
the document review process has extended beyond the traditional 
subjects of SNMP MIBs and AAA. For example, as part of the IETF 
CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP 
Taxonomy Document [RFC4118]; Dorothy Stanley organized an ad hoc 
group for this purpose. IEEE 802.11 has also reviewed [IDSEL] and 
[IABLINK]. Within IETF, IEEE 802 comments are resolved using normal 
WG and IETF processes. 


IETF participants can comment as part of the IEEE 802 ballot process, 
regardless of their voting status within IEEE 802. Comments must be 
composed in the format specified for the ballot, and submitted by the 
ballot deadline. 
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1.8. EtherType Allocation 


The EtherType field is very limited, so that allocations are made 
solely on an "as needed" basis. For related uses, a single EtherType 
should be requested, with additional fields serving as sub-protocol 
identifiers, rather than applying for multiple EtherTypes. EtherType 
allocation policy is described in [TYPE-TUT]. 


While a fee is normally charged by IEEE 802 for the allocation of an 
EtherType, IEEE 802 will consider waiving the fee for allocations 
relating to an IETF standards track document, based on a request from 
the IESG. 


2. Security Considerations 


As IEEE 802 becomes increasingly involved in the specification of 
standards for link-layer security, experience has shown that it is 
helpful to obtain outside review of work-in-progress prior to 
publication. This has proven somewhat challenging since access to 
IEEE 802 work-in-progress documents is often tightly controlled. For 
example, special permission had to be obtained for IEEE 802.111 to be 
able to circulate a version of its security standard-in-progress for 
review. A liaison between an IEEE 802 group and an IETF WG can help 
in obtaining the necessary level of review. 


Experience has also shown that IETF standards may not be written to 
the level of clarity required by the IEEE 802 standards process. In 
the case of EAP [RFC3748], the process of developing the EAP state 
machine specification [RFC4137] proved useful in uncovering aspects 
requiring clarification, and the joint review process exposed IEEE 
802 and IETF documents-in-progress to wider review than might 
otherwise have been possible. 


Similarly, the development of [IEEE-802.11i], [RFC3748], [KEYFRAME], 
and [RFC4017] led to a deeper understanding of the limitations and 
security vulnerabilities of the EAP/AAA system. As described in 
[Housley], it is not advisable to develop new AAA key management 
applications without completing a security analysis, such as the 
analysis provided in [KEYFRAME]. 


Due to weaknesses in the RADIUS specification [RFC2865], it is 
relatively easy for protocol extensions to introduce serious security 
vulnerabilities. As a result, IETF review of IEEE 802 RADIUS 
extensions is advisable, and the RADIUS IANA Considerations [RFC3575] 
have been revised so as to require such a review in most cases. 
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Appendix A. Relationship History 
A.1. MIB Development 
A.1.1. Bridge MIB 


The relationship between IETF and IEEE 802 began in the late 1980s 
with SNMP MIBs developed for the original IEEE 802.1D standard. 
Because the IEEE specification [IEEE-802.1D] contained only a 
functional definition of the counters and operations, the IETF’s 
Bridge MIB WG took on the role of defining the Bridge MIB [RFC1493], 
which was published as an RFC. Fred Baker and later Keith McCloghrie 
served as chairs of the Bridge WG. 


The Bridge MIB combined the work of Keith McCloghrie, Eric Decker, 
and Paul Langille, with spanning tree expertise provided by Anil 
Rijsinghani. Mick Seaman (author of 802.1D) and Floyd Backes (who 
had written the code for Digital Equipment’s spanning tree 
implementation) were the main contacts within IEEE 802.1. Since 
Mick, Floyd, Anil, and Paul all worked for Digital Equipment 
Corporation at the time, much of the coordination between IEEE 802.1 
and the Bridge MIB WG took place in the hallways at Digital, rather 
than within official channels. 


A.1.2. MAU and Hub MIBs 


In the early 1990s when IEEE 802.3 was completing the first Ethernet 
standards, SNMP was not yet the dominant network management protocol. 
As a result, a /’/protocol independent’ MIB is included in Clause 30 of 
the IEEE 802.3 standard [IEEE-802.3], which is updated each time the 
Ethernet standard is enhanced to support higher speeds. In parallel, 
IEEE 802 participants interested in network management were active in 
the formation of the IETF HUBMIB WG, which took on the task of 
transforming IEEE 802 definitions into SNMP MIBs documented as 
Standards Track RFCs. This included Dan Romascanu, Chair of the IETF 
HUBMIB WG since 1996. 


The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3 
standard is the starting point for the Ethernet MIB, but at the same 
time reserves the right to deviate from the IEEE model -- either to 
cover only part of the capabilities offered by the standard or to add 
MIB objects that are not directly derived from the IEEE model (mostly 
implemented in software). If management needs lead to requirements 
for hardware support, the IETF HUBMIB WG is to provide this input to 
IEEE 802.3 in a timely manner. 
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Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued 
for more than a decade until today, mostly based on the work of a few 
editors supported by their companies, who are taking the IEEE 
standards and mapping them into a management data model and MIBs. 
Work items include: 


— The Hub MIB [RFC2108], which has gone through three iterations, 
and is probably ending its evolution, as repeaters are less used 
in Ethernets. 

-— The MAU MIB, which has been updated each time a new Ethernet speed 
is developed, with [RFC3636] accommodating 10-Gbps Ethernet. 

-— The Ethernet-like Interfaces MIB was not originally a work item 
of the HUBMIB WG, but the WG took responsibility for a revision, 
published as [RFC3635]. 

- The WAN Interface Sublayer MIB [RFC3637] and the Power Ethernet MIB 
[RFC3621] were developed in IEEE 802.3 and the IETF HUBMIB WG. 


In 2000, an official liaison was established between IEEE 802.3 and 
the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liaison. 

The conditions of the liaison agreement allows editors and other 
participants in the IETF HUBMIB WG access to work-in-progress drafts 
in IEEE 802.3 on a personal basis, for the purpose of working on MIBs 
before the release of the standard. However, the username and 
password for IEEE 802.3 document access are not for publication on 
any IETF website or mailing list. 


A.1.3. 802.1p/Q MIB 


In 1996 as the 802.1p and 802.10 [IEEE-802.10] standards were being 
completed, a need was perceived for development of an SNMP MIB, based 
on the management clauses of those standards. IEEE 802 management 
clauses are written in a manner that was independent of any protocol 
that may be used to implement them. 


At that time, there were a number of proprietary VLAN management MIBs 
that were both inadequate and difficult to understand. As a result, 
there was a need for a more comprehensive, simpler model for VLAN 
management, along with the priority and multicast filtering 
management also defined by these standards. 


A small group of participants from the 802.1 WG began working on the 
problem independently, then combined their work. The original 
authors of the Bridge MIB, on which some of the work was based, 
reviewed the initial work. 
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By the end of 1997, the work was ready for review by a larger 
audience. Andrew Smith worked with Keith McCloghrie, chair of the 
Bridge MIB WG (dormant at the time), to obtain a meeting slot at the 
March 1998 IETF meeting. After this, review and development of the 
MIB continued on the IETF standards track. 


During the development of [RFC2674], there was no official inter- 
working between the IETF Bridge MIB and IEEE 802.1 groups. 
Development of this MIB was successful, because the main developers 
(Andrew Smith and Les Bell) were involved in both the IEEE 802.1 and 
the IETF Bridge MIB WGs. 


4. 802.3ad and 802.1X MIBs 


As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was 
decided that it would be better to develop a MIB as part of the 
standards, rather than wait until an IETF WG was formed, and develop 
the MIBs separately, so as to avoid a significant time lag in their 
development. 


As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most 
familiar with SNMP MIB development, he put together the initial MIBs 
based on the management framework the groups had come up with. 
Additional assistance was then received for both MIBs from within the 
TEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both 
standards, acted as editor of the MIBs as well. 


The problem with IEEE 802 developing these MIBs without IETF 
involvement was the lack of review. IEEE 802 members are generally 
not familiar with MIBs, and very few comments were received as part 
of the balloting process for either MIB. 


In the case of the IEEE 802.3ad MIB, this meant that basic errors 
were not discovered until just before publication. Unfortunately, by 
then it was too late, and the corrections submitted to the IEEE 
802.3ad chair and document editor did not get applied to the 
published version. 


Subsequent to the publication of [IEEE-802.1X], the IEEE 802.1X MIB 
was reviewed within the Bridge WG, and several syntax errors were 
found. These have been corrected in the version of the MIB module 
that was developed as part of [IEEE-802.1X-2004]. However, while 
[IEEE-802.1X-MIB] was originally published as a work in progress 
within the Bridge WG, there was not sufficient interest to complete 
its publication as an RFC. As a result, the draft has now expired. 
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A.1.5. 802.1t, 802.1lu, 802.1v, and 802.1w MIBs 


802.1t and 802.1lu were minor amendments to the 802.1D and 802.10 
standards, requiring some additions to the MIB published in 


[RFC2674]. 802.1v was a new feature extending the VLAN 
classification schemes of 802.10, also requiring extensions to 
[RFC2674]. 802.1lw was a new version of Spanning Tree, requiring 


rewriting of part of [RFC1493]. 


When Les Bell took on the role of Chair of the IETF Bridge MIB WG in 
2001, these issues were raised as new work items and two volunteers 

were found to become editors of the Internet-Drafts. A work item was 
also included to publish the IEEE 802.1X MIB as an Informational RFC. 


This approach worked well for a while, but it then became difficult 
for the participants, including the editors and the Chair, to sustain 
a level of interest sufficient to overcome the difficulties 
introduced by budget cutbacks. As a result, the drafts have now 
expired, although there are no significant technical issues 
outstanding. 


A.2.  AAA/EAP 


Since the late 1990s, IEEE 802.1 has been involved in work relating 
to authentication and authorization [IEEE-802.1X], which led to 
discovery of issues in several IETF specifications, including 
[RFC2284] and [RFC2869]. Similarly, IETF participants have uncovered 
issues in early versions of the RADIUS usage specifications such as 
[RFC3580], as well as the IEEE 802.1X state machine [Mishra]. 


In order to address these issues and ensure synchronization between 
IEEE 802.1 and the IETF EAP and AAA WGs, a liaison arrangement was 
utilized during the development of [IEEE-802.1X] and 
[IEEE-802.1X-2004]. 


IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11F have also 
become dependent on EAP and AAA work. This relationship was more 
challenging since IEEE 802.11 required development of EAP methods and 
the EAP Key Management Framework, which represented substantial new 
IETF work, as opposed to the clarifications and updates required by 
IEEE 802.1. 


A.2.1. IEEE 802.1X 
IEEE 802.1X-2001 [IEEE-802.1X] defined the encapsulation of EAP 


[RFC2284] over IEEE 802, as well as a state machine for the joint 
operation of IEEE 802.1X and EAP. 
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During the development of IEEE 802.1X-2001, several problems were 
discovered in the specification for RADIUS/EAP [RFC2869], and as a 
result, work was begun on a revision [RFC3579]. In addition, 
clarifications were required on how RADIUS attributes defined in 
[RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162] 
would be interpreted by IEEE 802.1X implementations. To address 
this, a non-normative RADIUS usage appendix was added to 
[IEEE-802.1X], and published as [RFC3580]. 


Subsequent to the publication of [IEEE-802.1X], a formal analysis of 
the IEEE 802.1X state machine by the University of Maryland disclosed 
several security issues [Mishra]. Discussion within IEEE 802.1 
pointed to lack of clarity in [RFC2284], which resulted from the 
absence of a specification for the EAP state machine specification. 


At that time, EAP was handled within the IETF PPPEXT WG, which was 
largely inactive. In order to undertake work on a revised EAP 
specification as well as the specification of the EAP state machine, 
the IETF EAP WG was formed in July 2002. Bernard Aboba, a 
participant in IEEE 802.1 as well as PPPEXT, was named co-chair. 


Work on the EAP state machine [RFC4137] and revised EAP specification 
[RFC3748] proceeded in parallel within the EAP WG, with issues or 
changes in one document requiring changes to the other document, as 
well as revisions to [IEEE-802.1X-2004]. The revised RADIUS/EAP 
specification [RFC3579] was also reviewed within the EAP WG, since at 
that time the RADEXT WG had not yet been formed. 


The revision to IEEE 802.1X [IEEBE-802.1X-2004] included the 
following: 


—- a revised RADIUS usage appendix based on [RFC3580] 

- clarifications based on [RFC3579] 

— a revised IEEE 802.1X state machine, based on [RFC3748] and 
[RFC4137] 


Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748], 
and [RFC4137], a liaison was established between IEEE 802.1X-REV and 
the IETF EAP WG in August 2002. This enabled participants in the 
IETF EAP WG to obtain access to the IEEE 802.1X revision in progress. 


IEEE 802 groups are duty bound to consider all comments received, 
regardless of their origin. This allows IETF participants to comment 
as part of the IEEE 802 ballot process, regardless of their voting 
status within IEEE 802. Where there is active cooperation, IETF WGs 
may be made aware that IEEE 802 ballots are occurring and that their 
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comments are welcome. IEEE 802.1X-REV and IEEE 802.111 ballots were 
announced on the EAP WG mailing list, as are IEEE 802 interim meeting 
arrangements. 


Similarly, during the IEEE 802.1X-REV ballot process, comments were 
received relating to [RFC3748], [RFC4137], and [RFC3579]. These 
comments were tracked on the EAP WG Issues List, and were 
subsequently addressed in the documents. 


In April 2003, [RFC3580] was approved by the IESG for publication as 
an RFC, and in May 2003, [RFC3579] was approved for publication as an 
RFC. The review process for both drafts involved bringing the 
documents to IETF last call, and then reposting the IETF last-call 
announcement on the IEEE 802.1 mailing list. While ballot comments 
on IEEE 802.1X-REV were also reflected in changes to both documents, 
it was necessary for both documents to be approved for publication as 
RFCs well in advance of Sponsor Ballot, in order to ensure that RFC 
numbers would be assigned in time, so as to avoid delaying 
publication. 


Overall, despite the complex inter-dependencies between 
[IEEE-802.1X-2004], [RFC3748], and [RFC4137], the documents were 
produced without undue delay. This was largely due to the work of 
joint participants in IEEE 802.1 and IETF EAP WG. 


A.2.2. IEEE 802.11i 


IEEE 802.11i was chartered to specify security enhancements to 
[IEEE-802.11]. Since [IEBEE-802.11i] utilized IEEE 802.1X, it 
depended on [IEEE-802.1X-2004]. As a result, IEEE 802.11i and IEEE 
802.1 held joint meetings at IEEE 802 plenaries and established a 
liaison arrangement that permitted members of either group (as well 
as EAP WG participants) access to IEEE 802.111 work-in-progress. 


Since [IEEE-802.11i] depended on [IEEE-802.1X-2004], it inherited the 
dependencies of [IEEE-802.1X-2004], including work on EAP, EAP 
methods, and AAA support for EAP. In addition, since IEEE 802.11i 
utilized EAP for key management whereas [IEEE-802.1X] does not, 
additional security requirements arose with respect to EAP methods. 


In February 2002, IEEE 802.11 sent a liaison letter to the IESG 
[IEEE-80211Liaison1l] requesting additional work on EAP, EAP methods, 
and EAP key management. This letter was presented at the second EAP 
BOF at IETF 53, and was used as input to the EAP WG charter. In 
March 2003, another liaison letter was presented, providing further 
clarifications on requirements for EAP method work 
[IEEE-80211Liaison2]. This included a request from IEEE 802.111 for 
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the EAP WG to consider changing the mandatory-to-implement EAP method 
within [RFC3748], so as to provide a method meeting the security 
requirements of IEEE 802.11i. 


During IETF 56, the request for changing the mandatory-to-implement 
method was considered by the EAP WG. A recommendation was made by 
the Internet Area Director Erik Nordmark that the IEEE 802.11i 
requirements be documented in an RFC and that the EAP WG consider the 


security requirements for EAP methods in various situations. It was 
recommended not to change the mandatory-to-implement method, since 
the EAP WG was not chartered to do work on methods. However, it was 
decided to produce a document describing the EAP method requirements 
for WLAN usage. This document was subsequently published as 
[RFC4017]. 


Most recently, IEEE 802.11r has been involved in discussions relating 
to fast handoff, which may potentially require AAA extensions as well 
as changes to the EAP key hierarchy. However, the direction of this 
work has not yet been determined so that no liaison request has been 
formulated yet. 


In April 2003, Dorothy Stanley was appointed liaison from IEEE 802.11 
to the IETF, in order to help coordinate between IEEE 802.11 and IETF 
WGs, including AAA, BMWG, CAPWAP, and EAP. 


3. IEEE 802.11F 


IEEE 802.11F was chartered with development of a recommended practice 
for Inter-Access Point Communications. As part of development of an 
Inter-Access Point Protocol (IAPP), it was necessary to secure 
communications between the access points, as well as to support the 
reverse resolution of the MAC address of the previous access point to 
its IP address, so as to allow the two access points to communicate 
via IAPP. Since the two access points might not be on the same link, 
Inverse ARP [RFC2390] was not considered sufficient in all cases. 


IEEE 802.11F elected to extend the RADIUS protocol [RFC2865] to 
provide inverse address resolution as well as IPsec key management. 
This was accomplished via use of Vendor-Specific Attributes (VSAs), 
as well as new RADIUS commands, added through definition of 
additional values for the RADIUS Service-Type attribute. Asa 
result, IETF review was not required under the IANA considerations 
included in [RFC2865]. Subsequently, the RADIUS IANA considerations 
[RFC3575] were revised so as to require IETF review in most cases. 
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No liaison arrangement was developed between IEEE 802.11F and IETF 
WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants 
access to the IEEE 802.11F specifications prior to publication. Once 
TEEE 802.11F entered into Recirculation ballot, only comments 
relating to changes in the specification could be considered. As a 
result, issues raised relating to the IEEE 802.11F RADIUS extensions 
were rejected. 


IEEE 802.11F was a Trial Use Recommended Practice. The IEEE 802 
Executive Committee approved its withdrawal on November 18, 2005. As 
a result, the RADIUS parameters allocated for use by IEEE 802.11F are 
available to be reclaimed. 
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